home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0143.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  1.8 KB  |  45 lines
  1. NNTP's model for keeping per-user seen state has two problems:
  2.  
  3. * It needs each message to have a unique-within-group identifier which
  4. is preserved across sessions.  For performance reasons, it is a good
  5. idea for these identifiers to be strictly ordered.  IMAP would either
  6. have to add such a construct, or declare one of the existing
  7. constructs as having this property.  My preference would be for
  8. INTERNALDATE to have this property.
  9.  
  10. * Storing this type of state information on the client is contrary to
  11. the goal of nomadic access.  Users cannot access the server from
  12. different clients without moving the state information between the
  13. clients.
  14.  
  15. In some sense, we have to paint ourselves into one corner or another.
  16. We have to pick either the client or the server as being responsible
  17. for keeping the per-user seen state.  We can (and should) make it
  18. possible to do it the other way, but one model should be the rule and
  19. the other the exception.  Otherwise, different clients will handle
  20. this different ways and confusion will reign.
  21.  
  22. I suppose a good tack a client implementation could be "try to keep
  23. /SEEN state on the server.  If this isn't possible, keep the state
  24. yourself."  Such a client could detect whether FETCHing a message
  25. causes the /SEEN flag to be set.
  26.  
  27. > I'm hoping IMSP can be used to bring the per-user
  28. > state file to the client from wherever it might be stored. 
  29.  
  30. An IMSP client can store almost anything it wants in an IMSP option.
  31. The difficulty is getting different clients to use the same
  32. conventions for storing the same information.
  33.  
  34. Similarly, an IMAP server implementation could use some external
  35. distributed database to store the per-user state.  I plan to use this
  36. approach if/when we get around to implementing replicated bboards.
  37.  
  38. -- 
  39. _.John G. Myers        Internet: jgm+@CMU.EDU
  40.             LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
  41.  
  42.  
  43.  
  44.  
  45.